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ABSTRACT 


The problem addressed by this research is that there does not exist a command and 
control system for the next generation U.S. Naval amphibious class of ship, LPD-17. A 
system is needed that coherently displays information required by commanders to make 
timely and correct decisions. This research examines this problem in the context of 
designing a user-interface display that will access data on the ship’s underlying network to 
exercise command and control 

The approach taken to solve the problem has four parts. First, system requirements 
were captured by interviewing 23 senior officers with command-at-sea experience to 
isolate design features they require from such a command and control system. Second, a 
mock-up display was designed based on these requirements, the mock-up was then 
iteratively tested in the fleet with subject matter experts to ensure it captured the required 
elements of command and control. Third, a user-interface display was then constructed 
using a personal computer and Asymetrix application Multimedia Toolbool™, that is, a 
prototype was made without connecting to the underlying data. Fourth, this prototype was 
then iteratively reviewed during design by fleet operators to validate that the command 
and control process could be executed from this workstation. The result of this research is 
a set of 18 example displays that will be forwarded to NAVSEA and the contractor for 


consideration during actual system design. 
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I. INTRODUCTION 


This thesis addresses the design of a prototype human-computer interface for a 
command and control system which will be in place on the next generation 
amphibious platform: LPD-17. The Naval Sea Systems Command (NAVSEA) is 
charged with developing this interface, and has already produced a preliminary fiber- 
optic based network, the Integrated Interior Communication and Control (IC)? System, 
which will provide the required data for command and control. This research 
incorporates data gathered during interviews of Commanding Officers of surface 
combatants; it evaluates and distills design features they would desire from such a 
command and control system. A set of engineering design recommendations is 
proposed for the system’s informational interface. 

The thesis has four parts. The introduction provides an interpretation of the 
general problem and NAVSEA’s current solution to it. The second part reviews the 
methods used to extract, isolate, and integrate command and control design 
recommendations. The third part reviews the analytic interpretation of users’ desires; 
how these desires were translated into system characteristics, and how these 
characteristics were incorporated into prototype displays. The final part, the 
discussion, critically evaluates the present method’s findings and products, and 


recommends future courses of action. 


A. NATURE OF THE PROBLEM 


This section discusses problems associated with current command and control 
systems. It identifies the problems experienced on surface combatants and discusses 


why it is important to accommodate these problems during the design of new systems. 





Two broad shortfalls account for usability 1 problems with command and 
control systems used in the surface Navy today: 


* There is a lack of understanding about how the user reads, interprets, and uses 
information, and 


+ There are few user inputs during the design process. 


By extension, these deficiencies are at the root of two common human-computer 
interface weaknesses: 


+ User-defined information requirements are not readily available; as a result, 
interface displays do not adequately depict what the user wants to see. 


+ Information displayed in lieu of that which the user wants is often difficult to 
comprehend in a timely and efficient manner. 


A third related problem deals with the complexities involved with designing a 
system to support command and control on U.S. Navy ships. The warfare environment 
in which these ships operate is continually changing, ultimately compressing the 
battlespace time-line. This change in warfare, in the face of advancing technology, 
threatens to overwhelm the decision-maker during the process of command and 
control. Potentially too much information is made available and the user is forced to 
deal with the serious problems associated with inductive 2 logical processes. The users 
are forced to select small bits of information from the vast amounts of data available to 
comprehend the situation and reach a decision. When existing deficiencies are 
combined with the changing complexities of surface warfare, proper design of the 
user interface becomes one of the most important aspects to consider during the design 


and development of the system itself. 


| Usability is related to the effectiveness and efficiency of an interface, and to the 
user’s reaction to that interface (Hix, 1993). 


2 Inductive reasoning involves drawing conclusions from specific events. The lexical 
definition of “inductive” is “...inference of a generalized conclusion from particular 
instances...” (Websters, 1990, pp. 615) The opposite of inductive reasoning is 
deductive reasoning —a conclusion reached from observing generalities. 


Tactical displays have not improved dramatically until the last few decades. 
From the days of Nelson’s Trafalgar in 1805 when messages were sent by flag signal, 
to the fleets of World War Two when radar and plexiglass grease boards were first 
used, much of the information that was passed along was hearsay. The data used for 
command and control was what someone else said, or saw. In the recent past, and with 
the advancement of electronic devices, displays now can accurately depict real-time 
data; but while the typical decision process has not changed, the workload on the user 
has continued to increase. “Modem computer power has opened the possibility of 
augmenting, assisting, and supplementing the decision process of commanders by 
synthesizing for display the information on decision alternatives.” (Snyder, 1993, pp. 
63) Effective design of command and control interfaces must ensure that computers 
assist in reducing the workload and help solve problems associated with decision 
making. 

The heart of the problem is straight-forward. Decision aiding interfaces used 
today often provide the user with too much data and not enough information. As 
technology advances and the volume of information available to the decision maker 
expands, the user needs help to discern the available options from a tactical 
perspective. As present and future tactical encounters become increasingly complex, 
decisions and actions are, and will continue to be, time constrained; multiple decisions 
and required actions must be made in a matter of seconds. Decisions must be made in 
milliseconds and use all relevant information at the time. The relevant information 
must be isolated, redundancies and ambiguities must be eliminated, and the system 
must provide information when and how the operator or decision maker needs it. 

Data and information are different, and this difference must be clarified. In the 
past, these two terms were used interchangeably, but today’s saturated information 
environment highlights a significant difference in their meaning. The International 
Standards Organization (ISO) defines data as “...a representation of facts, concepts, or 
instructions in a formalized manner suitable for communication, interpretation, or 


processing by human beings or by automatic means.” (American, 1972, pp. 33) 


Information is defined as “...the meaning that is currently assigned to data...” 
(American, 1972, pp. 63) An effective user-interface is one that displays data so that 
information is effectively and effortlessly imparted to the user. 

To fully understand command and control and how it relates to the surface 
Navy, this section will review the following four areas: 


+ The Basics of Command and Control. The traditional elements of 
command and control are discussed. Command and control is defined, and a 
model of how decisions are made is presented. 


+ Increasing Complexities of Command and Control. The reasons for the 
increase in information flow and the changing complexities in command and 
control systems are explored. 


+ Case Studies: A review of user-interfaces. Two studies are conducted and 
user-interfaces are compared. The first study reviews the incident of USS 
VINCENNES and the shoot down of a commercial airliner. This is an 
example of how the Navy’s most advanced command and control—and 
weapon system—did not lead its users to the proper decisions. The second 
study reviews the Integrated Condition Assessment System (ICAS), a 
computer based analysis and diagnostic tool used to monitor onboard 
equipment. This system has extensively involved the intended operator in the 
initial design of the interface. 


* Human Performance in Command and Control. How human capabilities 
and limitations come into play during decision making is reviewed. 


1, Command and Control 

The following reviews command and control to provide the reader with a very 
basic background in command and control—what command and control is, and what 
elements are involved with it. Contemporary command and control components are 
first reviewed to familiarize the reader with what is commonly available in the fleet. 
Command and control is then defined, followed by a model which displays the basic 


steps associated with command and control. 


a. Contemporary Command and Control Systems of the Surface 
Navy 

In the surface Navy, command and control systems that are 
predominantly in use are products that were designed and built during the period from 
the 1960’s to the 1980’s—a 20 year period during which the application of computer 
technology began. Today, however, many of these systems are obsolete, in part, due to 
rapidly advancing technology and the long development cycle these systems required, 
and in part, due to the slow military procurement process. To understand the problems 
that exist with current command and control systems, it is important to know the basic 
components that are available to assist with decision making. Typical command and 
control systems used by today’s surface Navy involve a combination of both computer 
based and non-computer based components to help the decision-maker. The following 
components comprise a typical media mix: 


* computer monitors or large display screens, 
* automatic status boards, 

* grease boards, 

+ hand written pass-down logs, and 

+ internal and external communications. 


Using such a media mix, the user is required to shift his attention between the display 
devices to retrieve essential pieces of information. For a number of reasons, these 
systems—systems which should support decision making during the process of 


command and control—can be designed to better support the user 





b. Command and Control Defined 
The Joint Chiefs of Staff define “command” as 


The authority which a commander of the military service lawfully 
exercises over subordinates by virtue of rank or assignment. 
Command includes the authority and responsibility for planning the 
employment of, organizing, directing, coordinating, and controlling 
military forces for the accomplishment of assigned missions. It also 
includes responsibility for health, welfare, morale and discipline of 
assigned personnel. (Joint Chiefs of Staff, 1972, pp.77) 

This definition implies specific action taken by the commander—organizing forces for 
optimal performance, directing force actions to accomplish a mission, or acting to 
achieve established goals. 

The commander exercises command through a process called command 


and control. Command and control is: 


The exercise of authority and direction by a properly designated 
commander over assigned forces in the accomplishment of the mission. 
Command and control functions are performed through an 
arrangement of personnel, equipment, communications, facilities and 
procedures which are employed by a commander in planning, directing, 
coordinating, and controlling forces and operations in the 
accomplishment of the mission. (Joint Chiefs of Staff,1972, pp.77) 


“\.commanders must be given certain specific capabilities that include the ability to 
communicate to higher and lower command levels, obtain, process, analyze, 
synthesize, and display information.” (Adriole, 1990, pp. 67) 

c. A Model of the Command and Control Process 

Command is the charge of the commander. Command and control is 
the process the commander uses to exercise command. Command and control reflects 
decisions which enable the commander to impose or express his will to, or on, 
subordinates. A highly simplified approach which diagrammatically represents the 
command and control process is depicted in Figure 1, on page 7. 

To evaluate the situation and determine the appropriate response, the 
commander must fully comprehend his continually changing environment. The 


commander must assess the situation to determine how to act. In assessing the 


situation, he must observe the information displayed by the supporting system, process 
what he is looking at, and compare what (he thinks) exists with what must be done to 
reach the desired goal. The commander must then decide the best course of action, 
and act. Simply stated, the commander must determine: 


+ What is happening? And, 
+ What can I, or should I, do about it? 


Systems that are to support command and control must help the user with the first step 
of the decision process: they must help the user assess the situation. Specifically, a 
command and control system must assist in observing, processing and comparing 
information—not data—so the operator can make better, faster decisions. It is task that 


is becoming more difficult as technology advances and surface warfare changes. 





Does the representation reflect reality? 





1b. What does this data I am looking at mean? 
process What can I do? 


a lef compare _| What is the current state I am in? 
compare What is the desired state? 
1; i 


What is the environment? 





‘What is best course of action? 

















Figure 1: Model of the Basic Steps Followed during Command and Control 


2. Increasing Complexity of Command and Control 

The compression of traditional battlespace in littoral 3 warfare, coupled with 
the proliferation of modem anti-ship weapons has created a serious challenge for 
today’s naval tactician. The human ability to recognize, evaluate, and react to the 
rapid flow of various types of information—tactical, own ship and administrative— 
with non-integrated shipboard systems has simply become physically and mentally 
overwhelming. If decision aids are to effectively guide the user to make correct 
decisions systems designed to assist decision-makers must be designed differently 
than they have been in the past. 

The changing role of the U.S. Navy continues to drive the development and 
production of new command and control systems. As stated in the Navy and Marine 
Corps White Paper ...From the Sea, “The future vision of the Navy will focus on 
strategic deterrence and defense, forward presence, crisis response, and 
reconstitution.” (U. S. Navy, September 1992, pp. 1) The demise of the Soviet Union 
and the rapid worldwide expansion of advanced technology to Third World countries 
have resulted in a rapid shift away from emphasis on open-ocean global! warfare to 
regional or limited conflicts involving Third Word nations in littoral waters. 

a. Impact of Littoral Warfare 

The littoral environment is characterized by dense commercial air 
traffic and merchant shipping which presents challenges to command and control 
systems and their operators. This environment and the projected threat will challenge 
the detection range, reaction time, defensive performance, and display mechanisms of 
the system used against the threats. The battlespace in which shipboard systems are to 
react in will be limited (Qusbome, 1993). “Facing the future, we must prepare to deal 


with a foe at ranges so close that the incoming weapons are at best only a few seconds 
away.” (Owens, 1993, pp. 90) 


3 Littoral warfare is the placement of traditionally open-ocean warships in a coastal 
environment in support of troops on land. 


b. Impact of Increased Complexity in Information Systems 

In addition to the rapidly changing warfare environment in which the 
Navy operates, each successive generation of warship has become technologically 
more complex. Present-day command and control systems, and procedures, must 
accommodate the explosion of data and the associated complexities of information 
distribution. In the near future, all voice, video, and data will be transmitted across a 
common medium—fiber optics. The subsequent integration of this data using 
common computers and databases will allow for the real-time display of any 
information that is conceivable. The challenge no longer exists in detecting and 
recognizing data but in selecting the essential information from this huge amount of 
data required to make a time critical decision. 

The more technology advances, the more complex command and 
control becomes. To ensure operators make the best and fastest decisions possible, the 
following must be accomplished: 


+ Improve integration and increase the automation of sensors, weapons, and 
display systems to shorten reaction time and coordinating responses. 


+ Enable the Commanding Officer, and subordinate watchstanders, to direct 
and monitor the overall operation of on board systems in this environment. 
(Ousbore, 1993) 


* Provide seamless command, control and communications to effectively 
operate in this complex sea-air-land battle. 


Accomplishing these tasks will lessen the complexities, and relieve much of the 


burden associated with decision making. 


3. Case Studies: A Review of Two User-Interfaces 

As the command and control process continues to become more complex, so 
does the process of designing command and control systems. The display element of 
decision aiding equipment—the human-computer interface that the decision maker 


will use to access data—is becoming one of the most crucial elements of design. 


The tactician of tomorrow is waiting for the designer of today to 
create a system that will help him understand his environment so that 
he can fight a better fight and live another day. (Willey, 1988, pp. 292) 


Research into the elements of command and control is not a new field, yet the 
manner in which information is displayed has not adequately focused on the end-user. 
Computer system interfaces must be designed with the user in mind. System designers 
must consider the human element. Data must be conditioned and displayed so that it 
becomes an effective tool for decision makers. 

In today’s high-tech environment, systems can provide more data than the 
human can process. The mental act of processing streams of rapidly changing data 
from multiple sources often induces information overload, a situation where more 
information is provided than an operator can handle. The same information at 
sufficient volumes with insufficient time in which to process it can also cause a 
breakdown in communication between operators. As previously discussed, both 
advancing technology and the compression of the traditional battlespace have made 
the flow of information virtually unrestricted. Interfaces designed to support 
command and control of surface combatants must accommodate and compensate for 
the possibility of operator information overload. The continually complex and ever 
changing environment of the surface Navy demands that computer systems must be 
designed around the conditions in which they will be used. Command and control 
systems must reflect how human performance is affected by the characteristics of that 
work environment. 

Two case studies follow. The first is a review of the shoot down of Iran Air 
flight 655—an A-300 Airbus—in the Persian Gulf in July 1988 by USS VINCENNES 
(CG-49)4. This event clearly shows that the AEGIS weapon system interface—in all 


essence the shipboard command and control system—could have been better designed 


4 USS VINCENNES is a Ticonderoga Class Cruiser. This ship uses the AEGIS 
Weapon System, the most advanced computerized shipboard weapon system based 
around a 3-dimensional radar, Anti-air warfare is the primary mission of this class of 
ship. 
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to accommodate the strengths and limitations of its operators. The system was not 
“user friendly:” the results were tragic. The second study reviews the Integrated 
Condition Assessment System (ICAS), a real-time computer-based analysis and 
diagnostic tool used to monitor on board engineering equipment. This system 
successfully focused on the needs of the intended user by keeping the subject matter 
experts involved throughout the design process. 

a. USS VINCENNES: Was it Only Operator Error? 

The accurate display of timely information on U.S. Navy ships greatly 
affects command decisions. This case exemplifies how the technologically advanced 
AEGIS Weapon System may not have effectively guided its users in making correct 
decisions. A summary of the incident is provided in Appendix A, on page 55 

(1) Design Weaknesses in VINCENNES’ System. The written 
reports, published after the incident—including the official investigation conducted by 
Rear Admiral Fogarty—and testimony from a House Armed Services Committee 
review concluded: 


+ the downing was “not the result of negligent or culpable conduct...” (Fogarty, 
1988, pp. 43) 


+ the Commanding Officer “...[acted] properly and responsibly in responding to 
an unknown threat, holding his fire until the last possible minute.” (Hill, 
1988, pp.108) and 


+ the AEGIS weapon system performed excellently—as it was designed (Hill, 
1988). 

The Fogarty report did not find any malfunctions by the AEGIS 
weapon system; however, it did recognize that specific pieces of equipment were 
misused by individual operators, resulting in erroneous reports of the aircrafts’ 
descending altitude and IFF. Testimony from human factor specialists however, did 
find fault with the design of the AEGIS weapon system, “...human error probably 
contributed to the accident, but not in the way the Fogarty report contends, ‘It was 
human error’, he says, ‘on the part of the people who designed the system.”” (Hill, 
1989, pp. 113) 


The Fogarty report did not find fault with the system; however, 
it is apparent from the result of this incident, the loss of 290 lives, that the AEGIS 
system—the “cutting-edge” of technology employed by the U.S. Navy—was not 
thoroughly designed with the user in mind. The report did not say that the AEGIS 
weapon system was not “user friendly” but the following events did occur: 


* operators misidentified the airliner, 
* operators incorrectly determined that the airliner was decreasing in altitude, 
* operators misread the aircrafts IFF 5, 


* operators incorrectly determined that the airliner was outside of the 
commercial air corridor, 


* one operator incorrectly pushed an action button 23 times trying to get the 
system to perform (Hill, 1988, pp. 204) and, 


+ those in the chain of command on VINCENNES, including the Commanding 
Officer, did not use information presented to them at their consoles, 
information which would have accurately indicated that the aircraft was 
indeed neither descending in altitude, nor preparing to take an attacking 
posture. 


The report did not state that the AEGIS weapon system failed to 
display information in a manner that was intuitive to the user. That omission, however, 
is one of the conclusions which can easily be drawn. Had design issues, like the 
intuitive display of information, and human factors issues, like mental processing 
capabilities and limitations, been adequately addressed earlier, the operators may 
never have been in a situation where so many disjoint errors would have resulted in a 
mistake of this magnitude. 

b, Integrated Condition and Assessment System (ICAS) 
The Integrated Condition and Assessment System (ICAS) will provide 


future generations with the ability to retrieve all required data about a shipboard 


5 Identification Friend or Foe (IFF) is an electronic challenge and reply system that 
uniquely identifies aircraft. This system is required on all aircraft. 
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engineering plant from a personal computer monitor. This system is currently being 
designed by the NAVSEA, Controls and Monitoring Systems Group, and although it is 
not labeled as such, designers are using a user-centered approach to design the ICAS 
interface. Intended-users with significant fleet experience have provided the basic 
requirements around which the system, and intuitive interface, are being designed. 
These intended-users are the driving force in determining the system characteristics. 
This type of design approach will allow designers to initially build and 
later modify the display in accordance with the desires of the users. It is essential to 
ensure that these user-defined requirements are tailored from the beginning with 
consideration into how the intended-user will “see” and “process” these displays. 


Human factors must be considered during design. 

4, Human Factors in Command and Control 

Human factors is the study of human behavior based on empirical 6 testing. 
The goal of human factors in interface design is to make systems usable. Usability is 
the optimization of human performance by: 

* maximizing information transfer, 

+ reducing errors, 

+ increasing throughput, 

* maximizing user satisfaction. 

Design of command and control systems must ensure that the display is 
intuitive and natural for the end-user. The user should not have to adapt to the 
interface. When designing command and control systems, human factors must be 
realized and accommodated. The display of information elements is critical to the 
success of a command and control system. Design must focus on the desires and 


limitations of the end user. The former Commander of the Joint Chiefs of Staff, 


Admiral WJ. Crowe, recognized that improvements were required in the command 


6 Empirical is defined as relying on experience or observation alone. 
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and control displays of the AEGIS weapon systems. This recommendation came after 
the VINCENNES incident: 


... Irecommend that some additional human engineering be done on 
the display systems of AEGIS. The objective would be to better equip 
it for assisting with rapid decisions in a situation such as VINCENNES 
confronted. It seemed to our inexperienced eyes that the 
Commanding Officer should have some way of separating crucial 
information from other data. Moreover, the vital data should be 
displayed in some fashion on the LSD 7 so the Commanding Officer and 
his main assistants will not have to shift their attention back and forth 
between displays. (Crowe, 1988, pp. 8) 





a. Human Performance: Capability and Limitations 

Human performance must be recognized and considered, it must have a 
direct impact on the design of a decision-aiding system. As exemplified at the 
VINCENNES hearings 


..the ship’s sophisticated AEGIS radar and computerized battle 
management system worked properly, but that some of the men 
monitoring the screens and digital displays may have distorted the 
information they were receiving... (Moore, 1988, pp. Al) 


For example, human short term memory is an intermediate stage of 
memory between sensory storage and long term memory that can last up to 
approximately 18 seconds and is limited to seven plus or minus two items. Moreover, 
to increase the processing ability, people “chunk” data; that is, data is organized into 
recognizable groups. By grouping information in this way, the human processing 
capability increases dramatically. Recognizing these strengths and limitations, and 
tailoring a system to limit the processing weaknesses and exploit the strengths should 
bea focal point of design for a user interface. 

b, Human Factors as a Force Multiplier 

If not recognized, human memory and processing can become a force 


attentuator, thereby limiting capabilities and preventing the users from obtaining the 


7 Large Screen Displays (LSD’s) are 42” x 42” wall mounted displays used on AEGIS 
cruisers and destroyers for command and control. 
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desired goal. By recognizing these limitations and designing human-computer 
interfaces with them in mind, human mental ability can become a force multiplier. 

By emphasizing the importance of human factors, complex systems can 
be designed to be “user friendly.” Interface displays are the keystone of command and 
control systems and the decision making process on board surface Navy combatants 
Correct design of interfaces will strengthen and assist the ability to effectively apply 


assets in order to achieve military objectives. 


B. PROPOSED SOLUTION 


This sub-section introduces a proposal to fix the deficiencies that exist in 
today’s command and control systems. The Total Ship Integrated _ Interior 
Communication and Control (IC)? program is a NAVSEA initiative to solve the 
problem of information explosion on board U.S. Navy ships. This system will be 
reviewed, followed by a discussion of the Command Function—the display element of 
(IC)?. (IC)? will differ from existing command and control systems by providing: 


* seamless command, control, and communications because all shipboard 
components will be connected to a real-time fiber-optic network, 


+ information available to the Commanding Officer and his subordinate 
watchstanders will provide the ability to monitor and direct on board systems, 
and, 


+ interface displays will consider the human element, human-computer 
displays will be intuitive yet provide comprehensible information. 


1, NAVSEA’s Integrated Interior Communication and Control (IC)? 
System 
NAVSEA has designed and successfully demonstrated the abilities of a new 
information transfer system. The next generation amphibious ship—LPD-17—will 
have a complete fiber optic network system that will connect all shipboard equipment 
and sensors. The Integrated Interior Communication and Control (IC)? System, will 


integrate the entire ship as a warfighting unit. The flow of data will be unrestricted. By 
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effectively harnessing the data that exists on this network, the command and control 
display element, called the Command Function, will be a critical element in the overall 
system. 

Implementation of (IC)? will replace the way current interior communication 
collect, process, distribute and display orders. Through the use of (IC)?, information 
will be available to assist decision making. The challenge is to correctly and 
methodically determine what to display and how to display it to support the user. 

a. Description of (IC)? 

(IC)? is the means by which future ships will exercise command and 
control. (IC)? permits individual ship systems to improve their connectivity and 
versatility by using newly available technology to improve conventional interior 
communication designs. This information management approach will screen, fuse and 
integrate all shipwide data into real-time information to aid in the command and 
control of the ship. (IC)? will allow surface ship fighters to evolve from the traditional 
use of compartmented information into the integration of the ship as a total entity. 
LPD-17 will operate for the first half of the 21% century 8. 

(IC)? equipment will pass all data, information, voice, video and orders 
between on board users. The components consist of: 


+ a shipboard data network, 

+ a video distribution system, 

* a voice distribution system, 

+ the information transfer cable plant, and 
the Command Function. 


The first four components are specific hardware that will facilitate the collection, 
processing, and transfer of data. They are not addressed in this research. The 


Command Function is what users will use to access (IC), and is discussed next. 


8 LPD-17 has an initial operational capability (IOC) of 2002. 
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b. Introduction to the Command Function 

The Command Function is the display element of (IC). The Command 
Function will enable operators to exercise command and control from a workstation 
using real-time information that traditionally was unavailable, or at best, late. This 
display will provide fused summary data of shipboard functions to facilitate command 
and control. This workstation which uses a 25 inch color graphics monitor will enable 


its to monitor systems and provide guidance to others. 


C. THESIS SCOPE 


This thesis provides prototype displays for the Command Function—the 
display element of (IC)? system. The design recommendations and displays will be 
forwarded to NAVSEA for consideration during interface design and development. 

The shortfalls that exist in current command and control systems are by- 
products of a flawed design process. Systems in use today often lack a crucial design 
element, input and feedback from the intended-user to determine the required system 
functionality. Systems are often not designed around what the user actually wants; 
consequently, the systems are not “user friendly.” 

The term “user friendly” in engineering parlance means “usable.” Usability 
relates to the effectiveness and efficiency of the interface, and to the users reaction to 
the interface. To ensure usability designers must accomplish these tasks: 

+ Determine what the intended-user requires from a new system. 

+ Establish a foundation of ideas based on the inputs of operational experts and 


the desires of intended users. Base the mock-up and initial prototype on these 
requirements. 


+ Document these findings in such a manner that system characteristics can be 
outlined and so that other designers can further modify and build onto the 
system. 


The next chapter reviews the method used to design the Command Function. 
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i. METHOD 


This thesis develops functional specifications, including the required 
functionality and associated system characteristics, and develops prototype displays 
for the Command Function of LPD-17. The method used to design those prototypes is 
discussed below. The process adopted closely follows a set of contemporary 
commercial design guidelines (Mayhew, 1992) comprised of five notional phases. 
These phases are: 


(1) a definition of the system’s purpose, 

(2) the development of the functional specifications, 
(3) the actual system design, 

(4) system development, and 

(5) test and implementation. 


The present discussion addresses the second phase of these design guidelines, 
the development of the functional specifications. Functional specifications are 
determined by first identifying what the system needs to do from a user’s perspective, 
then secondly, isolating the system characteristics needed to meet those requirements. 
A task analysis was used to systematically isolate and define the performance 
requirements imposed on the system by the operator. This chapter describes two sets 
of procedures employed for the task analysis of LPD-17’s Command Function. 

The first set concerns the five design phases and their associated steps, 
including a review of NAVSEA’s work on the (IC? program. It then focuses on the 
methods used to extend NAVSEA’s effort in designing the interface for IC. The 


second set discusses the task analysis procedure itself and how it was performed. 








A. DESIGN PHASES 


Mayhews’ (1992) approach to interface design was selected because it is 
simple, concise, and provides clear-cut guidance. Moreover, the approach is 
commonly referenced in both commercial and military documents concerning human- 
computer interfaces. Table 1, on the following page, depicts the five phases which 
comprise this approach a nd their completion status with respect to accomplishment by 
NAVSEA, and the areas which will be addressed by this research. The shaded portions 
highlights the two specific areas—the task analysis in Phase 2, and the mock-up and 
prototype in Phase 3—presently addressed. The table shows that despite the 
accomplishments to date on “Scoping the System,” the next phase, “Developing 
Functional Specifications,” must be addressed. The main step in that work is to 


conduct a task analysis. 


B. TASK ANALYSIS 


The task analysis’ approach adopted identifies the systems’ functional 
requirements by observing and interviewing its intended end-users. In short, it solicits 
inputs from subject matter experts to specify product requirements. This approach 
studies the user’s actions, work-flow patterns and demands, and evaluates human 
information processing limitations, user capabilities, and task characteristics. The 
results become the basis for the conceptual design of a high-level mock-up which, in 
tum, is iteratively critiqued by the intended-user. The task analysis therefore, is a 
critical step in the design process. If it is incorrectly done, the resultant system may 


not meet user expectations and operator performance could suffer. 
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Action Item Status 














































Phase Name and Required Actions 
a val Status® Remarks 
1 | SCOPE The scope of the system has been defined by the military requirements. The user profiles 
Define the purpose of the system. [N] | are highlighted by specific job requirements—in this case itis that of an officer who 
Conduct user profiles. IN] | would command a ship of the class LPD-17. 
1 IFICATION, This is where interviews of subject matter experts begin. The intended end-user 
: - [1] | determines the demanded system functionality. System designers then determine the 
Discuss training and documentation. L1 | associated system characteristics to meet these demands. 
mu | DESIGN ; ‘Actual design begins with a high-level conceptual design called a mock-up. This is based 
[ cd ial poceup T] | on data gathered during the task analysis. The mock-up is the basis for the prototype. 
ggg Stablish a style guide, ‘The prototype is a representation of the system’s core functionality. The mock-up, and 
: Spey sos T] | later the prototype, are iteratively critiqued by subject matter experts and intended-users. 


Establish a prototype test plan. 
Test the user interface. 

















FOLLOW-ON RESEARCH TO BE CONDUCTED BY NAVSEA & CONTRACTORS 





DEVELOP 
Establish training and documentation. 
Develop a user-interface test plan. 














FOLLOW-ON RESEARCH TO BE CONDUCTED BY NAVSEA & CONTRACTORS 








TEST & IMPLEMENTATION 
Test the user interface. 





Evaluate the user interface. 


























FOLLOW-ON RESEARCH TO BE CONDUCTED BY NAVSEA & CONTRACTORS 








denotes items completed by NAVSEA. 


[1 denotes areas addressed by his thesis, 
[D1 éenotes items that remain to be completed. 
b.  Amock-up is made from paper-and-pencil, It is disposable tool which forms the basis for the prototype display. 


Table 1: The Phases and Status of Interface Design for LPD-17’s Command Function 





The field situations in which command and control systems operate are 
extremely complex, change very rapidly, involve diverse operator job requirements, 
and are typically characterized by extraordinarily high-levels of information exchange. 
Users’ information requirements often tend to be stated in ambiguous, imprecise, and 
in a context-dependent manner. These user information requirements were 
systematically identified by interviewing a sample of officers who have had 
command-at-sea experience. Contents from the interviews were then subjected to a 
content analysis which produce a set of discrete information requirements. The 
following introduces the sampling method used and the task analysis’ tools employed 
to express the required functional specifications. These specifications were then used 
to develop the prototype displays for the Command Function. The task analysis is 
described first, followed by a review of the method used to produce the mock-up and 
prototype displays. 

1. Sample of Subject Matter Experts 

Structured interviews were conducted with fifteen senior officers—members 
of the Surface Warfare Officers College Command, the Senior Officer Ship Material 
Readiness Course, and the Naval War College—who had command-at-sea experience 
on a broad range of different ships. The communities that were represented included, 
CRUDES, Amphib, Minesweeps, Combat Logistic Force, and Carriers. 9 These field 
grade officers, Commanders and Captains, were chosen because they were subject 
matter experts with a record of consistent proven performance at sea, and were 
recognized as leaders in the surface community. The interviews were designed to tap 
what they considered to be the critical information requirements needed to meet 
command and control requirements for their respective ships. The interviews with 
senior officers were followed by interviews with 23 junior officers, Lieutenants, who 


had experienced duty at sea and who were prospective users of the Command 


9 Surface ships are divided into groups, CRUisers and DEStroyers are called 
CRUDES, amphibious capable ships are called Amphibs; Combat Logistic Force 
ships are used for supply. 
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Function. The goal of these interviews was to determine what users thought was 
required from a system designed to fully support shipboard command and control. 

Extensive written comments were recorded during all interviews, and later 
evaluated to discern patterns of responses which highlighted what these officers 
thought they needed to effectively execute command and control at sea. Moreover, the 
comments were examined to reveal desired design features absent from _ existing 
systems. The information needed to exercise command and control and the desired 
new design features were incorporated into the mock-up and prototype displays. 

2. Task Analysis’ Tools 

An analytic method called Quality Function Deployment (QFD) was used for 
the task analysis. QFD is a methodology aimed at satisfying the consumer by 
translating their demands into design goals. It is based upon a simple premise: by 
building a system around the desires of intended-users, operator performance 
improves. QFD, a design method is commonly used throughout industry, is briefly 
reviewed below before its application to the present research is described. 

a. Introduction to Q9FD 
QED is a way to establish quality in a product’s design, manufacturing, 

and service; quality becomes a focal point in the initial stages of design and remains 
an important design goal throughout the products life-cycle. This approach bases 
product design on the demands of the user. It is a methodical plan for producing 
quality by reviewing the product at each stage of its design and development. The 
QED method of design was adopted for two reasons: it uses interviews and anecdotal 
narrative data which are relatively easy to collect; and it produces detailed 
documentation as the method is applied. This documentation ensures that user- 
provided data is readily available for the primary design phase and subsequent design 
changes. The system’s final design becomes directly linked to documented user 


requirements. 
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b. QFd Tools Used In The Task Analysis 

Eight tools were used in the task analysis: the first four to determine 
user demands, and the second four to determine the concomitant system requirements. 
Table 2, on the following page reviews the eight tools. This table lists the goals, 
procedures, and the results of the application of each QFD tool. Operator demands 
were first identified using the following steps: 


+ Intended users were interviewed to determine their demands. 
* User comments were translated into engineering design language. 
+ The data was organized into logical categories. 


* Specific characteristics needed to achieve the specific user-demands were 
identified. 


After this data was collected and organized, a conceptual model—the first mock-up 
interface—was made for review. 
The following section discusses the manner in which these design 


characteristics were incorporated first into the mock-up, and then into the prototype. 
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Tool Name Goal Procedure Results 
CUSTOMER DEMAND | Determine what the | + Interview the intended user +A list of demands that are recorded in 
LIST users” want + Document the users’ demands—in their own words the users’ own words 

+ List the demand 
+ Verify the list of requirements with the intended user 

AFFINITY DIAGRAM | Onganize the data | + List the each demand on an index card + A grouping of the demands into logical 
collected during « Separate the card based on logical grouping categories 
interviews. 

TREE DIAGRAM. Determine how the | + Identify one statement that clearly and simply states the core issue + Three levels of demands are produced 
demands will be | * Generate all possible tasks required to support this statement The lowest level, the third level, 
accomplished—what | + Evaluate these ideas, determine if they are within the project scope determine the "required system 
subordinate tasks are | + Place these tasks in a tree structure, the root being the initial statement cheracteristics, and the identification of 
required missing items 

DEMANDEDQUALITY | List all demands and | + List highest-level demand, to the right list the associated lower level + An organized chart with the demands of 

CHART supporting task as | demands the user, beginning at the highest level, 
determined by the | * Continue until all have been listed and ending with a level of detail that 
user can be used to determine required 

characteristies 

QUALITY Translate demands | * List the lowest level (third level) demands * Translation of demands into high level 

EXTRACTION TABLE | into required high- | + Determine the required characteristics to meet these demands characteristics 
level characteristics 

AFFINITY DIAGRAM | Orgenize the data | + List the each demand on an index eard * Grouping of characteristics 

+ Separate the card based on logical grouping 
TREE DIAGRAM Find supporting tasks | + Identify one statement that clearly and simply states the core issue + High and low level characteristics 
+ Generate all possible tasks required to support this statement 
+ Evaluate these ideas, determine if they are within the project scope 
«Place these tasks in a tree structure, the root being the initial statement 

QUALITY List the required | + List highest level charncteristic to the right list the associated lower level | + Organized chart of required 

CHARACTERISTICS __ | characteristics characteristic characteristics to meet the 

CHART + Continue until all characteristics have been listed user demands 














Table 2: The Tools of QFD: Goals, Procedures, and Results 





C. MOCK-UP AND PROTOTYPE 


User requirements identified by the task analysis were incorporated in the 
mock-up and prototype. Data from the task analysis and preliminary design decisions 
already made by NAVSEA were merged and depicted in a paper-and-pencil mock-up, 
which was the point of departure for an iterative series of design sessions. This process 
ultimately optimize user-acceptance by incorporating user-defined functional 
requirements. Given the absence of specific design guidelines for the initial interface 
design, the process used to translate user-requirements into the mock-up was intuitive. 
It was based on familiarity with the subject matter, familiarity with the criterion 
environment, and a review of pertinent human factors and computer literature. 

1. Design Tools 

The prototype displays were developed with Asymetrix™ object-oriented 
application Multimedia Toolbook™. The design was conducted using an Intel 486 
processor, Window NT™ operating system, and a 21” NEC™ MultiSync 6FGp high- 
resolution color monitor. The prototype screens were printed on a Shinko CHC-S446i 


printer. 


D. SUMMARY 


Mayhews’ (1992) approach to system design was adopted to develop the 
Command Function. Quality Function Deployment (QFD), a variant of task analysis 
methodology, was used to identify user’s functional requirements and by extension, 
the associated system characteristics. Officers with command-at-sea experience were 
interviewed and their desires and opinions concerning command and control display 
requirements were solicited, These narratives were analyzed to extract common 
themes which formed the basis for a mock-up of the Command Function. The next 


chapter describes the results of applying this methodology. 
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Il. RESULTS 


The application of the user-centered design method previously discussed 
yielded products: a set of user-defined system requirements and system characteristics, 
and the interface display characteristics derived from those requirements. The first part 
of the present chapter discusses the results obtained from the task analysis. It presents 
the functional specifications essential for the Command Function; that is, the desired 
functionality of the system as stipulated by a representative sample of users, and the 
system characteristics. The second part reviews the actual interface; that is, prototype 
display screens. Two screens are provided to exemplify how the user-defined 
requirements were incorporated in the design of this interface. The remaining screens 
can be reviewed in Appendix B. The chapter concludes with a summary of these 


results. 


A. TASK ANALYSIS 


The results of the task analysis are displayed in Tables 3 and 4. These tables 
depict summary data collected from interviews, and subsequently translated into 
specific engineering system characteristics. These data collectively comprise the basis 
for the Command Function design characteristics. 

Table 3, on the next page, lists the task requirements and resulting design 
characteristics the system must meet from an operator’s perspective while performing 
the job: that is, in exercising command and control. Table 4, on page 29, lists the 
design requirements and associated system characteristics of the equipment designed 
to support command and control. Both tables reflect the data collected from the 


previous steps used in the task analysis. 
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Job Function 


Supporting Task 


System Characteristics 





PROVIDE C? TOOLS 


Display current tools available 


* Display all data from status boards 

* Display data in real-time 

* Integrate data from phone-talkers 

* Show equipment status, call signs, 
and battle group responsibilities 





Use video 


+ Allow selection of any video camera 





Track organic units 


+ Track own ships units display 
~ bearing / range, loadout 
~ limiting factors, destination 





Display surveillance picture 


+ Integrate radar displays 





Show restrictive events 


+ Model current situation’s events 
+ Display limiting events 
~ ‘show percent of completion 
+ Prevent errors during these events 





Compare data 


+ Provide list of available options 
+ Provide traditional checklists 





ASSIST USER IN 
PROCESSING DATA 


Avoid task overload 


+ Recognize memory capacit 
‘Provide all required data 
+ Use recognition instead of recall 

+ Use pictures / graphics instead of text 





Assure fidelity 


+ Display data as it is expected 
* Display data realistically 





Ensure interpretability 


+ Use pictures and graphics. 
+ Ensure logical representation 
+ Use familiar icons and layouts 





Rank information 


+ Prioritize alarms 
+ Update displays based on importance 





ASSIST USER IN 
MONITORING AND 
CONTROLLING 
EQUIPMENT 





‘Show equipment status 


+ Display on / off / stand-by status 

+ Use color to amplify status 

+ Use pictures of equipment 

+ Display equipment in expected 
locations 

+ Display information as it is organized 
in text 





Allow trend analysis 


+ Provide access to databases 
+ Correlate trends 
+ Use graphs to display information 





Show configuration changes | * Display what changed and when | 


+ Tell the user why something changed 
+ Allow the user to select time limits of 
query 








Allow varied selection of 
‘equipment 


+ Allow queries of equipment 
*edtment difatbn system, and 
status 











Table 3: Job-related Requirements and Associated System Characteristics of the 
Command Function 
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Design Function 


ENSURE RELIABILITY 


Supporting Task 


Use both routine everyday 
events: 


System Characteristics 


+ Use inport and at sea 

+ Use to conduct everyday routine events 
and real-time operations 

+ Use to train personnel 





Use for emergent and 
special events 


+ Use for emergencies 
* Prioritize information 





Provide all the required 
tools in one place 


+ Display schedules 

+ Display training requirements and status 

+ Integrate video 

+ Access personnel records and reference 
publications 








Optimize system + Minimize system crashes 
performance + Prevent errors 
+ Respond in adequate time 
ENSURE EASE-OF-USE | Make system rapidly + Allow user to select desired display 
configurable information 





Access the information as it 
is expected 


+ Display elements logically 

+ Use pictures and graphics instead of text 
+ Do not require extensive learning 

+ Use traditional / expected colors 

+ Use traditional / expected layouts 





Prevent the user from 


* Make the display intuitive 














getting lost + Ensure navigation pathways are logical 
SUSTAIN COMMAND _ | Tailor the system like + Pass orders down only one level 
RELATIONSHIPS relationships on board + Pass information up only one level 
+ Screen certain data before entry on the 
network 
Limit access based on rank | + Limit access to data based on position 
or position + Require users to log in 
+ Provide information security 
USE IN PLANNING Use for C? planning + Display outcomes from potential 








changes 





Table 4: Design-related Requirements and Associated System Characteristics of the 
Command Function 
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B. MOCK-UP AND PROTOTYPE 


The mock-up and prototype were produced using the system requirements 
defined in the task analysis. These requirements were displayed in Tables 3 and 4. 
Recall that a paper-and-pencil design, a mock-up, was the basis for the prototype. The 
discussion now focuses specifically on the prototype itself. The prototype which 
evolved as a result of evaluating the mock-up. 

The prototype for the Command Function interface was designed in two parts, 
the background, and the specific screens. When observed by the user, the screen and 
the background appear as a single entity. Figure 2, below, shows the layering effect 
from an operators point-of-view. By designing the interface in two parts, screens with 
specific information can be layered on top of permanent data elements. 

The purpose and associated elements of both the background and specific 
screens are listed on page 32. First however, NAVSEA’s design specifications for the 


Command Function are reviewed. 


1, Operator Interface Design Specifications 









User views both 
screens as one... 











Figure 2: Command Function Interface Design 
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The basic operator interface design features of the Command Function have 
been stipulated by NAVSEA (1994). These features include the use of a 21 inch or 25 
inch high-resolution color graphics monitor with a touchscreen—in place of a 
traditional keyboard—for operator interaction, These two features, along with the 


user-defined functional requirements, are the basis for the prototype. 


2. Backgrounds 

The background was designed to display data required by all subsequent 
screens. These data elements provide amplifying information to assist the user in 
evaluating their environment. The background is divided into three parts to provide 
distinct separation of information elements. This separation divides information 
logically—as the user expects it—and reduces the possibility of operator sensory 
overload. The three groups are: 


* tactical summary, 
+ status windows, and 
* push buttons, 


The specific location of these elements on the background can be reviewed on Figure 
2, on the previous page. Although it is desirable to allow the user to configure the 
display as they see fit, these locations serve as the default. The main reason these 
groupings and locations were selected is that configuration reflects how and where the 
user traditionally expects to find this information. Table 5, on page 32, lists the three 
parts of the background and describes their purpose and specific components. 

There are two backgrounds used for the Command Function, one used with the 
departmental screens, and the other with the special evolution screens. The only 
difference between the two is the choice of push buttons: the main background allows 
navigations to the individual departments, the special evolution background allows 
navigations to special evolution screens. Table 6, on the next page, lists the navigation 


options of each background 
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Item Purpose Components 
TACTICAL Inform user of tactical situation | + Condition of readiness 
SUMMARY + Material condition 

+ EMCON posture and amplification 
+ HERO posture and amplification 

+ Waming / Weapon status 


A! 
+ Flight deck status. 
* Well deck status 
+ Ballast / de-ballast status and level at sill 





STATUS Inform user of ships parameters | + Ships course and spe: 
WINDOWS + Rudder angle indicator 
+ Latitude and Longitude read-out 
+ Selectable display: 
~ PIM information 
- Wind display, or 
- Weather display 
. Exuipment on-line display: 
gineering equipment, or 
- Combat System Equipment. 
+ Restricted Maneuvering Label 





PUSH Navigate to other screens + Equipment 
BUTTONS + Personnel 

+ New Messages 

+ Video 

+ Forward 

+ Backward 

+ Administration 

* Aviation 

+ Combat Systems 


. + Botbarked Forces 
+ Engineering 

+ Navigation 

* Operations 

+ Supply 

+ Special Evolutions 

















Table 5: Parts of the Background 








From this backgroun ‘The user can navigate to 


Main Default Any department screen 
Special Evolutions Sereen (and background) 








Special Evolution Any sial evolution screen 
ee Mala Default Screen (and background) 











Table 6: Navigating through the Command Function Screens 
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3. Screen 


The individual screens display specific information as the user navigates 


through each screen. This specific information is layered on top of the main or special 


evolution background. The screens themselves are divided into two groups: ship 


departments and special evolutions. 


The purpose of, and the display elements of the department screens are listed 


below, and on page 34. Due to the extraordinary amount of data present, the table has 


been divided into two parts, Table 7a and Table 7b. The purpose and display elements 


of the special evolution screens are listed in Table 8, on page 35. 











Screen Name Screen Purpose Display Elements On Screen 
ADMIN Provide typical * Gateway to SNAP Ill 
administrative data. + Provide at a minimum access 

~ personnel and training records 

~ past evaluations 

~ instructions, references and reports 

- ticklers and the plan-of-the-day 
AIR Provide data about 


embarked air element 


+ Tactical display® - default range set at 40 NM 
+ Aircraft summary display 
~ AIC#/ Brg /Rng / Fuel / Serial # or load / 
destination 
+ Aircraft flight plan 
~ integration of Air Tasking Order (ATO) 
+ Weather information (ceiling, visibility, density / 
pressure altitude, wind, dew point) 
+ Flight deck status 
+ Video selection - flight deck or well deck 
+ Ships tactical communication plan 
+ Push button to show boat schedule 





cs 


Allow for monitoring and 
controlling of Combat 
System equipment 


* Graphic display of equipment: 
- online, in stand-by, out of commission (OOC) 
+ Text field with above information. 
+ Ammunition status 
~ type and location, allowances: on board & training. 
* Video selection 
* Status window of background will automatically show 
the Engincering equipment display 





DECK 





Provide status of deck 
related equipment 








+ Tactical display - default range set at 15 NM 
= emphasis on own ships’ boats 
+ Graphic display of stern gate and well deck status 
~ well deck depth / percent ballast 
+ Field with Sea state information, hangar door status, 
life boat status, and anchor status 


+ Video selection - well deck and vehicle stowage. 








Table 7a: Department Screens and Associated Display Elements 


a, The tactical display is the integration of the ships position, a digital navigation chart, and the radar 
surveillance picture. Range and chart will be selectable, ships positioning on the display will be moveable. 
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Screen Name 


EMB 
FORCES: 


Screen Purpose 


Provide embarked Marine 
commanders information 
required for command and 
control of their troops 


Display Elements On Screen 


* Tactical Maps - integrated with tactical display 
~ allow overlays on land areas 
use for peueey 

+ Landing Serial Table 
- wave number / serial / craft / unit / beach / load 
- allow for amplification on demand 

* Graphic of percent of MOGAS on board 

+ Communication Field 
= circuit status and location 

*Go/ No Go button to direct troop movement 

+ Push button to display LFORM 
~ landing force operational reserve material 
= ordnance / equipment / rations / fuel 

* Summary field 
+ personnel on board, sea state, equipment 





ENG 


Allow for monitoring and 
controlling of Engineering 
equipment 


* Graphic display of ship with equipment status: 
- equipment on-line, stand-by, OOC 
+ Field with equipment information in text 
+ Fuel / water / aviation fuel graphs 
+ Push button to navigate to Damage control. 
* Status window of background will automatically show 
the Combat Systems equipment display 





NAV 


Provide information 
normally collected at the 
navigation table 


+ Tactical display - default range set at 10 NM 
~ provide specific navigation details on chart 
+ Call sign field 
+ Field with fix information 
* Status window of background will automatically show 
the Engineering equipment display 








OPS 


Provide tactical 
information 


+ Tactical display - default range set at 50 NM 
* Call sign field. 
+ Push button to display battle group information: 
~ responsibilities 
~ ships in company 
+ Push button for message retrieval 
~ allow query to database for received msg 
~ access files of stored msgs 
~ review new msgs 
+ Push button to display schedules 
~ integrate plan-of-the-day and schedule-of-events 
+ Push button to access communication information 





SUPPLY 





Provide status of Supply 
Department 





+ Hotel service status 
+ Budgets 

+ Supplies on board 
* Parts status 





Table 7b: Department Screens And Associated Display Elements (continued) 
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Screen Name 


Screen Purpose 


Display Elements On Screen 



































transition the ship into the 
most defensive posture 
available 





A/C LAUNCH Provide all required factical display - default range sel 15NM 
information for the launch | + Graphic display of flight deck, required winds for 
and recovery of aircraft specie deck spots 

+ Field with launch / recovery cycles 

+ Pitch and roll indicators 

+ Video of flight deck 

* Status window of background will automatically 
show the Combat Systems equipment display 

ANCHORING To anchor + See Sperry interface already designed 

BOAT OPS Provide all required + Tactical Display - default range set at 15 NM 
information for the launch | + Sea State indicator 
and recovery of boats + Field with launch / recovery cycles 

+ Wind di 
+ Field with stem gate status 
+ Video selection 

FIRE/FLOOD Damage Control + See CAE Link Damage Control Interface 

MAN OVER Provide quick and easy + Tactical display - default range set at 2NM 

BOARD entry of position of man ~ ship will be positioned in middle of screen 
overboard, and to provide __| + Push button for entry of position 
all required information for ~ green button for stbi 
recovery - red button for port 

+ Field displaying checklist for M.O.B. 
+ Field with information about OSCAR 
+ brg& mg 
- time in water 
_= water temp and stay time 
+ Field with course to steer to pick up man 
+ Field displaying ships’ boat status 
* Status window of background will automatically 
show the Engineering equipment display. 
* Status window of background will automatically 
show the Wind display. 

REPORTS Display reports which have | +8 o’clock report information 
been labor-intensive + 12 o'clock report information 

SEA DETAIL Provide all require + Navigation Display like tactical display but ships 
information for safe heading defaults to true north 
navigation while at sea + Field with navigation courses / speed distance 
deta remaininy 

+ Field with communication circuits 
+ Field with anchor status 

UNREP Provide information + Tactical display - to include own ships position, 
required for planning and and unrep location 
conducting an underway —_| Field with unrep ship data: CO /rig placement etc 
replenishment + Field displaying material for unrep / conrep 

+ Status bar and time-to-go displays 
| SHIP DEFENSE To quickly and effortlessly | + Tactical display - default range set at 1ONM. 


~ ships position in middle Of screen 

+ Push button activation of ships defensive systems 
= SLQ-32/ CIWS/ RAM 

+ Push button to set General Quarters 

+ Graphic summary of ships defensive systems 

+ Field with equipment on-line z 

* Status window of background will automatically 
show Combat Systems equipment display 

* Status window of background will automatically 
show graphic of wind display 





Table 8: Special Evolution Screens And Associated Display Elements 
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4. Example Display Screens 

Two screens of the Command Function, Figures 3 and 4, are included to 
provide the user with examples of how user-demands have been integrated with 
human factors to display what is desired—by the intended-user—in a logical and clear 
manner. The remaining screens are provided in Appendix B, on page 59. 

The first screen, Figure 3 on the next page, is the Main Default Screen. This 
screen will be used during normal operations. The screen is designed to provide the 
user with the elements normally required to exercise “routine” command and control. 
These elements are: 


+ a tactical display combining a digital chart, ships position, and radar 
surveillance 


+ selection of ship specific check-lists’ to guide the user through routine 
operations 


+a field displaying contact information. This pop-up field will correlate the 
text from the summary field with the actual contact location shown on the 
tactical display. 


The central focus of this Main Default Screen is on safety-of-transit, navigation and 
planning. Operations which require more in-depth information and/or guidance can be 
accessed at the touch of a push button. 

The second screen used for an example, Figure 4 on page 39, is the special 
evolution screen Sea Detail. This screen would be selected by the operator when the 
ship is conducting or planning precise navigation. The information elements of this 
screen include: 


+a tactical display with additional in-depth detail normally found on navigation 
charts 


* a pictorial display of the anchor status; the ready status of each anchor 
+a field displaying the course-to-steer, required speed, distance remaining in 
this navigation leg, and time-to-turn to the next course. Additional course 


information—the future courses and speeds—is also available at the touch of 
a button 


* communications information, including circuits that are on-line 
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Cc. SUMMARY 


The results are a set of design recommendations and the associated prototype 
for the command and control interface—the Command Function—on LPD-17. User 
demands have been evaluated and basic functional requirements associated with a 
surface ship command and control systems have been determined. Using these basic 
functional requirements, system characteristics of the Command Function were 
determined. These characteristics were tailored to meet the user-defined requirements, 


and were the basis for the mock-up and prototype displays. 


41 


42 


IV. DISCUSSION 


The prototype display screens for LPD-17’s Command Function, produced by 
the method adopted in this study, were presented and briefly discussed in the previous 
chapter. These displays are the tangible products of this design effort; but as noted here 
the selection and use of the design method itself departed from conventional practice. 
This chapter addresses the salient aspects of the design method adopted herein and 
uses the prototype display screens as a basis from which to discuss its general concepts 
and principles. The first section places the prototype screens in context; that is, they 
really reflect only a first generation design effort. The second section contrasts the 


current method with others commonly used today. 


A. PROTOTYPE DISPLAY SCREENS 


The two screens presented in the previous chapter reflect a careful accounting 
of user-demands and an incorporation of accepted design principles. These screens, 
however, are first generation displays and their design will require additional iterations 
during the remaining design phase itself, and later, during developmental and 
operational test and evaluation of the integrated system. The displays were designed 
based on inputs of the intended-users and shaped by technical literature from the fields 
of computer science and human factors. Again, these products reflect activity at the 
very beginning of the design phase. By presenting this first generation prototype to the 
intended-operator at this early design stage, the interface will be subjected to 
modifications based both on user-requirements and relevant technical literature. 
Accordingly, time is not wasted at a later and more costly, stage of development. This 
rudimentary interface is simply a point-of-departure for subsequent design 


enhancements. 
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The screens themselves reflect straight-forward design objectives. The 
arrangements of informational elements were designed to enable operators to access 
the information they need to efficiently and effectively exercise command and control 
on LPD-17. This stage of design took an iterative approach. Operational experts 
repeatedly evaluated the design to ensure the interfaces provided what they wanted, 


and displayed this information in a manner they clearly understood. 


B. DESIGN METHOD 


The interface between the operator and shipboard command and control 
systems is frequently cited as the weak link in the overall design of the integrated 
systems. To date, no particular school of design guidance has been accepted in either 
the rapidly advancing commercial sector, or the slow and methodical acquisition 
procedures of the Department of Defense. Computer system interfaces need to be 
designed around user-requirements to ensure acceptance, they must be “usable,” 

Selecting an interface design method must ultimately produce a “usable” 
system. User-centered methods provide the required iteratations during design and 
development to collect, represent, and analyze data obtained from the intended users. 
This process increases the likelihood that the resulting interface will display what the 
intended user actually wants, and consequently operator performance should improve 
as users come to rely on the system. 

The design methods employed to produce today’s computer interfaces for the 
surface Navy often do little to ensure cognitive compatibility, which is the extent that 
an interface accomplishes a task in the manner the user expects to accomplish that 
task. The resulting interfaces are, in general, not considered “user friendly”. In fact, 
end-users often wonder whether designers solicited opinions from fleet users during 
the design or if the interface was designed in a “box;” that is, in isolation. To provide a 


basis for comparison, the common method used today in interface design is contrasted 
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with the method used in the present research—a method committed to user-centered 
design. 

1, Methods Used Today 

Approaches employed to design interfaces today typically do not use 
procedures needed by designers to ensure that the systems’ broad design objectives 
meet a fleet operator’s requirements. There is insufficient design guidance and few 
design tools available to interface developers for them to consistently make fleet- 
relevant decisions during the design process. In military procurement programs, which 
are typically constrained by inflexible schedules and an intolerance to cost over-runs, 
designers tend to make decisions from a narrow technical engineering perspective 
which may not reflect a boarder operational fleet perspective. Many interfaces used in 
the surface Navy reflect this narrow engineering design perspective. 

The practice of relying on a contractor—typically cost and time constrained 
and removed from the fleet—to determine both system functionality and subsequently 
system design, is common. This practice of simultaneously relying on contractors, 
while not ensuring they solicit current fleet input, has an accepted practice in the face 
of increasingly complex systems, and increasingly complex informational 
requirements, both of which in tum are imposed by increasingly complex mission 
requirements. It is the operator, and by extension the mission, that is adversely 
impacted. Fleet personnel will readily adapt to design short-falls, but often, it is at the 
expense of mission capabilities. Generally operators are unaware of design 
alternatives, they use the tools that are available “....they generally accept the result 
because when you give them an application, the way it looks is the way it is.” (Nielsen, 
1994, pp. 378) Clearly, it is incumbent on the designers to provide the fleet with 
carefully considered designs which are fleet validated. 
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a. Reliance on Contractors in Determining System Functionality 

Relying on the commercial sector as the dominant source of design 
input is a poor way to determine system requirements. Although the commercial 
sector, or more specifically contractors, is often staffed with retired or ex-military 
personnel, these same people may not reflect today’s fleet operators. More specifically, 
the methods currently used by contractors are often personnel dependent. Employees’ 
memories, the breadth of their individual experiences, and the extent to which they can 
associate with their fleet counterparts become the foundation on which design 
solutions to contemporary problems are based (Nielsen, 1994). This method of design 
limits the range of possible solutions. Moreover, an experience dependent approach 
may possibly perpetuate design errors unrecognized in predecessor systems. 

Given the rapidity with which technology is advancing, design ideas, 
and both developmental and operational test and evaluation, must be based on today’s 
fleet. An iterative approach must be used to solicit inputs from both master-level 
operators—users of predecessor systems—and journeyman-level operators— 
intended-users of the new system. For the Command Function, the master is typically a 
Captain or Commander with command experience, and the journeyman is today’s 
Lieutenant. 

These groups have generational differences. Generational differences 
are perhaps best exemplified by the users’ “trust” in a new computer system. 
Differences in “trust” may simply reflect newer generations having greater access to, 
and consequently more use of, like systems. This variation in perspective can result in 
subtle differences in the system design features desired by the operator. The functional 
requirements of both groups must be met. Meeting those requirements entails a clear 


emphasis on what is euphemistically called “user-centered” design. 
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2. User-Centered Design 

The design process reflected in this research is a method based on user- 
centered design, It is not essential that one particular method is chosen over another, as 
long the method that is chosen focuses on the user and accommodates their 
preferences and requirements. In this regard, the present effort used Mayhew’s (1992) 
guidance, and by following its prescribed steps used the associated guidelines for an 
iterative approach to design. 

The focal point of user-centered design is obviously the user. For this approach 
to be successful, designers must understand the user. If they understand both 
demographic characteristics and fundamental job requirements, they then are 
positioned to actively solicit meaningful input for design. Fleet input, including initial 
ideas and subsequent evaluation, becomes the predominant criterion on which design 
decisions are based. User-determined requirements are solicited from both subject 
matter experts and the intended-operators. These anecdotal accounts of operators’ 
desires are then balanced with basic design principles. Transforming the users’ desires 
into system characteristics, and balancing these ideas with established design 
principles ensures usability. Models are used to represent system functionality and are 
iteratively evaluated by the user to assure fleet relevance. Two procedural elements of 
design, the sample of users which affect the design process, and the set of design 
principles used to produce the initial prototype are critical to the overall process. 

a, Sample of Users 

An important design element is gathering and interpreting fleet input. 
In the present case, inputs from subject matter experts located at the Naval Education 
and Training Center at Newport, Rhode Island were solicited. The Command Function 
itself is a tool used to support the command and control process. Naval organizations 
in Newport presented a broad range of diverse experience on command and control. 
As previously reported, extensive interviews were conducted with members of the 
Surface Warfare Officers College Command Staff, the Senior Officer Ship Material 
Readiness Course, and the Naval War College. Junior Officers, the eventual intended- 
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users of the Command Function, were found throughout the waterfront and on afloat 
units. Another excellent and concentrated source of junior officers was found at the 
Naval Postgraduate School (NPS) in Monterey. This School provided readily 
accessible volunteers with diverse backgrounds. Subject matter experts from these 
sources provided inputs to the design which reflect not only diverse technical 
backgrounds, but inter-generational aspects as well 

b. Basic Design Principles 

The basic principles used for the design of the Command Function 
interface are listed in Table 9, on page 50. These principles are a summary of ideas 
collected from the technical engineering literature encompassing interface design and 
from the common desires of fleet personnel. 

c. Future Research 

LPD-17’s Command Function interface is by no means complete. The 
prototype displays produced by this research are an initial step in the design phase. 
Further design is needed before the development phase begins and NPS can provide 
this work. NPS can provide subject matter experts with recent fleet experience and the 
technical design expertise needed to integrate this fleet experience with engineering 
principles to achieve the desired user-centered results. Student officers at NPS have a 
selfish interest to ensure that quality products are provided to the fleet, as they will 
soon return to sea. The six recommendations which follow provide additional avenues 
for further research at NPS. 


» Examine the information elements displayed on each screen. Continue to 
solicit fleet input to determine missing elements and to critique current 
displays. Verify that the colors, shapes, and layouts used to simulate the 
traditional environment are accurate. Modify and update the displays during 
this iterative process. 


« Evaluated the prototype display in a realistic shipboard environment. 
Allow intended-users to “play” with the prototype display in a shipboard 
environment. Real-time data is not required, operators will be evaluating the 
display screens. 
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« Conduct additional analysis of the data collected during the functional 
specifications. Review the data collected and weigh the user-determined 
functionality against the system characteristics. Use a method like QFD to 
determine the importance of each user-demand. Compare the results of the 
analysis with the prototype displays. 


+ Review the system display characteristics to determine which items a 
user might need to tailor. Review the situations this interface will be used 
in, and identify the particular elements an operator might need to change. 


+ Conduct Laboratory Experiments. Determine optimum displays to provide 
rapid recognition and maximum information transfer. Review how the use of 
color, shapes and information layout affects the users’ perception of the 
displayed information. 


+ Determine required element refresh rate. Determine the minimum graphic 
refresh rate for each specific display element. 
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Principle Meaning Way to accomplish 
ENSURE DESIGN IS “Make the job easier and | * Know the user 
USER-CENTERED better for the user, as + Involve subject matter experts, 

determined by the user.” | intended-users, and human 
factors experts during design 
+ Define requirements in the fleet 
+ Provide a system model for 
critique 
{____ 
RECOGNIZE HUMAN “Display information + Do not overload the user 
INFORMATION not data.” + Use cognitive directness 
PROCESSING + Draw on real world analogies 
CAPABILITIES + Organize displays to manage 
complexity 
+ Use pictures instead of text 
+ Display information the way the 
T 
ah user expects it 
MATCH THE SYSTEM “Speak the users’ + Access information logically 
WITH REAL-WORLD language.” + Do not require the user to learn 
new methods / tools 
PROVIDE “Follow expected + Be consistent 
CONSISTENCY AND conventions and + Keep displays simple 
ADHERE TO accepted standards.” + Use traditional colors / icons / 
STANDARDS shapes / coding 
+ Show the user what they expect 
USE RECOGNITION “Make information + Do not require the user to 
INSTEAD OF RECALL visible or easily remember information 
retrievable.” displayed elsewhere 
+ Provide all the tools required to 
perform a task 
PROVIDE AESTHETIC “Do not provide + Contain only the information 
AND MINIMALIST irrelevant information.” that is needed for that task. 
DESIGN 
ENSURE VISIBILITY “Keep user informed of | + Provide feed back to the user 
OF SYSTEM STATUS what is going on.” 











Table 9: Usability Principles for Design 


50 





C. CHAPTER SUMMARY 


A system design which focuses on the demands and desires of the intended- 
user is more likely to succeed than one which bases design decisions on limited 
technical and engineering inputs. By isolating and accommodating the user’s desires 
the interface will ultimately reflect what users want, therefore the likelihood that the 
interface will be both usable and relied on will increase. User-interfaces employed on 
board surface ships must reflect the desires and demands of the fleet. User input during 
the initial design and subsequent development is the key to both fleet acceptance and 


the production of a quality interface. 
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V. SUMMARY AND CONCLUSION 


The environment in which command and control decisions are made on board 
Navy ships is extremely complex. The advent of automated computer processing has 
increased the amount of data available to the operator, but this increase in volume has 
not reduced the associated workload on the operator. Changing mission requirements 
and technological advances have imposed additional responsibilities on the 
commander. Computer systems can be used to effectively harness the voluminous 
amounts of data and assist the operator in exercising command and control. The 
keystone to ship board command and control systems is the interface—the 
electronically mediated workspace used by the operator to access the underlying data. 

To effectively design and build a user interface designers must understand both 
the required elements of ship board command and control, and also the way these 
elements are used during the command and control process. Following systematic 
design procedures, these mission essential elements are captured and translated into 
system characteristics. This research followed a set of systematic design procedures 
and produced a prototype interface for command and control on board LPD-17. This 
prototype is the beginning of the design phase. It is a design based on two simple 
straight-forward considerations: provide what the user wants, and tailor those wants 


with acceptable design principles. 
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APPENDIX A. THE VINCENNES INCIDENT 
The following condensed details of the downing of Iran Air flight 655 by USS 
VINCENNES are taken directly from the official investigation. (Fogarty, 1988.): 
Summary: 


On 3 July 1988, the USS VINCENNES (CG 49), operating in the 
Southern Persian Gulf as a unit assigned to Commander, Joint Task 
Force Middle East, downed a civilian airliner, Iran Air flight 655 on a 
routine scheduled flight from Bandar Abbas to Dubai, with two SM-2 
missiles 10, 


Background scenario: 


In the three day period prior to the incident, there was heightened 
air and naval activity in the Persian Gulf. Iraq conducted airstrikes 
against Iranian oil facilities and shipping 30 June through 2 July 1988. 
Iranian response was to step up ship attacks. Additionally, Iran 
deployed F-14's from Bushehr to Bandar Abbas. U.S. Forces in the 
Persian Gulf were alerted to the probability of significant Iranian 
military activity resulting from Iranian retaliation for recent Iraqis 
military successes. That period covered the fourth of July weekend. 


During the afternoon and evening hours of 2 July 1988 and 
continuing into the morning of 3 July 1988, Iranian Revolutionary 
Guard Corps (IRGC) armed small boats (Boghammers, and Boston 
Whalers) positioned themselves at the western approach to the Straits 
of Hormuz (SOH). From this position, they were challenging merchant 
vessels, which has been a precursor to merchant ship attacks. On July 
2 1988, USS ELMER MONTGOMERY "!' was located sufficiently close 
to a ship attack in progress as to respond to a request for distress 
assistance and to fire warning shots to ward off IRGC small boats 
attacking a merchant vessel. 


3 July Surface Engagement: 
On the morning of 3 July 1988, USS ELMER MONTGOMERY was 


on patrol in the northern portion of the Straits of Hormuz. At 
approximately 0330Z, USS MONTGOMERY observed seven small 


10 A Standard missile (SM-2) is a medium range missile designed for surface-to-air 
engagements. 


1 Uss ELMER MONTGOMERY is an Oliver Hazard Perry Class Frigate, designed 
for anti-submarine and anti-air warfare 
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Iranian gunboats approaching a Pakistani merchant vessel. The small 
boats were reported by USS MONTGOMERY to have manned machine 
gun mounts and rocket launchers. 


Shortly thereafter, USS MONTGOMERY observed a total of 13 
Iranian gun boats breaking into three groups. Each group contained 3 
to 4 gun boats with one group of four boats taking position off USS 
MONTGOMERY ’: port quarter. At 0411Z, USS MONTGOMERY 
heard the gun boats over bridge to bridge challenging merchant ships 
in the area. USS MONTGOMERY then heard 5 to 7 explosions coming 
from the north. At 0412Z. “Golf Sierra” '2 directed USS VINCENNES 
to proceed north to the vicinity of USS MONTGOMERY and investigate 
USS MONTGOMERY ’s report of small boats preparing to attack a 
merchant ship. USS VINCENNES'’s helo (OCEAN LORD 25 / Lamps 
Mk III helo) on routine morning patrol, was vectored north to observe 
the Iranian small boat activity. USS VINCENNES was also monitoring 
a routine maritime patrol of an Iranian P-3 operating to the west. At 
approximately 0615Z, the USS VINCENNES’ helicopter was fired 
upon by one of the small boats. USS VINCENNES then took tactical 
command of USS MONTGOMERY and both ships proceeded to close 
the position of the helicopter and the small boats at high speed. As USS 
VINCENNES and USS MONTGOMERY approached the position of the 
small boats, two of them were observed to turn towards USS 
VINCENNES and USS MONTGOMERY. The closing action was 
interpreted as a demonstration of hostile intent. USS VINCENNES 
then requested and was given permission by CJTFME to engage the 
small boats with gunfire. At approximately 0643Z, USS VINCENNES 
opened fire and was actively involved in the surface engagement from 
the time Iran Air flight 655 took off from Bandar Abbas through the 
downing of Iran Air flight 655. 


During the course of the gun engagement of the Iranian small boats, 
the USS VINCENNES, at approximately 06542, had maneuvered into a 
position one mile west of the centerline of civilian airway Amber 59. 
The USS SIDES !3, transiting from east to west through the SOH, was 
approximately 18 miles to the east and became involved in the evolving 
tactical situation, 


12 Golf Sierra is the call sign of the Anti-Surface Warfare Commander. 


13 Uss SIDES, another Oliver Hazard Perry Class Frigate, was also assigned to the 
Persian Gulf, 
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Bandar Abbas / Iran Air flight 655 / air engagement: 


On 3 July 1988, at approximately 0647Z, an Iran Air Airbus 300, 
Iran Air flight 655, took off from the Bandar Abbas joint military / 
civilian airport destined for Dubai airport. The flight was a routine 
scheduled, international flight via commercial airway Amber 59. 14 


Vincennes — Critical Decision Window: 


At approximately 0647Z - Iran Air flight 655 was detected by the 
USS VINCENNE ’ AN/SPY-1A radar bearing 025 degrees, 47 NM 45, 
and was assigned TN 413116. The aircraft continued to close USS 
VINCENNES with a constant bearing, decreasing range. At 
approximately 0649Z, USS VINCENNES issued warnings on Military 
Air Distress (MAD) (243.00 Mhz) and at 0650Z began warnings on 
International Air Distress (IAD) (121.5 Mhz) to TN 4131 located 025 
degrees, 40NM from USS VINCENNES. 


At approximately 0650Z - several USS VINCENNES CIC personnel 
heard, on internal Combat Information Center (CIC) voice circuits, a 
report of F-14 activity. A momentary Mode II-1100 IFF \7 indication 
was detected which was correlated with an Iranian F-14. This was 
reported throughout CIC over internal CIC voice circuits. Continuous 
MAD and IAD warnings were ordered at 30NM (5 total warnings on 
MAD and 4 total warnings on IAD). USS VINCENNES continued the 
surface engagement and experience a foul bore in Mount 5118. In 
order to unmask the after gun mount, full rudder (at 30 knots) was 
applied. This added to the increasing tension in CIC. 


14 Commercial air ways are 20 miles wide, the latitude and longitude of the center of 


the airlane are published and readily available. 


15 A nautical mile (NM) is a unit of measurement at sea, based on the length of a 


minute or are of a great circle of the earth— equal to 2000 yards. 


16 Track number (TN) is how the Navy Tactical Data System (NTDS) distinguishes 
between different contacts. Each contact is assigned its own track number, commonly 


referred to as “track four one three one”. 


17 Identification Friend or Foe (IFF) is an electronic challenge and reply system that 


uniquely identifies aircraft. This system is required on all aircraft 


18 Mount 51 is the forward 5 inch gunmount located on the forecastle; the after 


gunmount, Mount 52, is located near the stern. 
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At approximately 0651Z - as TN 4131 closed to 28 NM, USS 
VINCENNES informed CJTFME that she had a closing Iranian F-14, 
which she intended to engage at 20NM unless it turned away. USS 
VINCENNES requested concurrence. CJTFME concurred but told USS 
VINCENNES to warn the aircraft before firing. Warnings continued, 
but no response from TN 4131 was received, nor did it turn away. 


At approximately 0652Z - warnings continued over both IAD and 
MAD. Still no response. Although TN 4131 reached the 20 NM point, 
the CO decided not to engage. The order was given to illuminate the 
contact with fire control radar. There were no ESM'9 indications. TN 
4131 was ascending through 10,000 feet. 


At approximately 0653Z, at 15-16 NM, the last warning over IAD 
was given by USS SIDES to the aircraft bearing 204 degrees to USS 
VINCENNES, range 15.5 NM. During the last 30 seconds of this 
minute, the CO made his decision to engage TN 4131. 


At approximately 06542, the CO turned the firing key. Two SM-2 
Blk II missiles left the rails. They intercepted Iran Air flight 655 at a 
range of 8 NM from USS VINCENNES at an altitude of 13,500 feet. 


(Fogarty, 1988. pp. 4-6.) 


19 Electronic Surveillance Measures (ESM) is used to detect electronic emissions, it is 
used to assist in identification. Its function is similar to a high-tech radar detector, 
commonly used in cars. 
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APPENDIX B. SCREENS OF THE COMMAND FUNCTION 


This Appendix displays the supplemental interface screens of the Command 
Function. The prototype displays included in this appendix are: 


+ Aviation Department 

+ Combat Systems 

+ Deck Department 

+ Embarked Forces 

+ Engineering Department 

+ Navigation 

* Operations Department 

+ Supply Department 

+ Special Evolutions Default 
+ Aircraft Launch 

+ Small Boat Operations 

* Man over board 

+ Special Report 

+ Underway Replenishment 
+ Ship Defense 


Each screen is a collection of information display elements. The display 
elements of each screen are listed in Tables 7 and 8, on pages 33 and 35 respectively. 
Certain screens are not included in this section. The Main Default Screen, and the Sea 
Detail Screen are on page 37 and 39. Displays for anchoring, and damage control— 
fire and flooding—have already been designed and developed NAVSEA sponsored 
contractors. These displays should be iteratively reviewed to ensure they provide the 


basic user-defined requirements, and that they adhere to sound design principles. A 
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weapon firing display is also not included. This interface in-and-of-itself is worthy of 
extensive research and should be addressed separately. 

These displays are prototypes, and accordingly they represent a proposed draft 
of the Command Function characteristics. To ensure a successful design of the of the 
Command Function interface, these displays must be continually critiqued and 
modified with the intended user in mind. The prototype screens that follow are 
reproductions from an interface development tool, Asymetrix™ Multimedia 
Toolbook™, they were designed to be displayed on a 21 or 25 inch high-resolution 


color graphics monitor. 
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